IBIS Macromodel Task Group Meeting date: 19 January 2021 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Rui Yang Luminous Computing * David Banas Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SAE ITC Jose Godoy SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Fangyi to add information on the new hybrid variant to his presentation. - Done. Fangyi to present the new slides today. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the January 12th meeting. Michael moved to approve the minutes. David seconded the motion. There were no objections. ------------- New Discussion: Redriver Flow Issues: Fangyi shared his updated presentation "AMI Redriver flow". Note: The slides were sent to ATM about 12 hours after the meeting and are available. Fangyi noted that variant 3 is the union of the previously discussed variants 1 and 2. (variant 3 was referred to as the hybrid variant in the previous minutes) Fangyi reviewed 3 new slides on variant 3. slide 10 - Variation 3: Combinations of Variants 1 & 2 This slide shows the possible inputs to and outputs of Init. slides 11 & 12 - Variant 3 notes Two new AMI Reserved Parameters are defined: - Init_Includes_Cumulative_Impulse - True/False - if True, this is variant 1. - Init_Returns_EQ_Filter - True/False - if True, this is variant 2. Fangyi noted that both of these should be Usage In. A model is a Variant 3 model if and only if its .ami file specifies one or both of these two new parameters. Any Variant 3 model must support the case in which both parameters are false (false is the default if either parameter is not in the .ami file), in which case the model operates according to the legacy flow. The new flow, proposed to overcome the issues in the current redriver flow, assumes that all models are Variant 3 models. No mixing with legacy models is supported, as they could corrupt the new flow. The new flow assumes all models are Dual, or they could be Init-Only with Init_Returns_EQ_Filter specified in the .ami file. The one exception is a terminal Rx with DFE, which must have a GetWave to support time domain simulation. The EDA tool must always set at least one of the new parameters to True for the new flow. Slide 13 (added to the slides emailed out after the meeting) includes a truth table for the 4 combinations of settings for the two new parameters, per Arpad's suggestion. Ambrish asked if we really gained much by using variant 3 as opposed to variant 1. He said he thought the need for two parameters with variant 3 was overly complicating things. Fangyi said one thing variant 3 supports over variant 1 is the ability for the EDA tool to provide a proxy GetWave for an Init-Only model (see bottom row of slide 9). Walter said another benefit is that the EDA tool can choose not to bother putting the crosstalk terms into the IR matrix input to Init. The tool could choose to do all the convolution externally. Fangyi agreed, assuming the tool/user know that the model does not need to know the strength of any crosstalk terms. Fangyi noted that, for simplicity, his table on slide 10 always assumes/shows the crosstalk terms are passed in. Ambrish asked if we couldn't implement variant 1 now and add variant 3 later if necessary. Arpad said that if an EDA tool developer is implementing variant 1, it's a small increment of work to add support for variant 2 as well and arrive at full variant 3 support. Curtis said that even variant 1 would require the addition of one new parameter to indicate variant 1 vs. legacy flow, and the extra complication of having a second parameter seemed worth it given the benefits of having variant 2 as well. Fangyi said that because the parameters are Usage In, a tool developer could choose to only support the variant 1 functionality if they wanted to. Arpad asked if we needed a straw poll to decide. Bob said he thought we should move ahead with variant 3. Ambrish asked to review the slides and decide at the next meeting. Fangyi took an AR to send the updated slides to the ATM list. Arpad took an AR to ask Steve Parker to post them to the ATM archives. Clock Forwarding BIRD (BIRD204) issue: At the December 15, 2020 meeting, Walter noted a problematic case. If the Data (e.g., DQ) model has Rx_Use_Clock_Input set to "Times", and the Clock model (e.g., DQS) does not return clock ticks, what should we do? Walter suggested that we should require the DQS model to have a GetWave function and to return clock ticks if the DQ model wants clock ticks as an input. Walter had suggested modifying the Other Notes for Rx_Use_Clock_Input to add: For the "Times" option, the Clock shall have a DLL with an AMI_GetWave that returns clock_times. Arpad asked if we needed a new BIRD for this, since BIRD204 had already been approved. Walter said we could instead leave BIRD204 as is and add this as an extra admonition to avoid this case. For example, we could add: For the "Times" option, the Clock should have a DLL with an AMI_GetWave that returns clock_times. The model maker cannot rely on all EDA tools generating clock ticks from a waveform in the same way, and it would be a burden on the EDA tool to find out that the Clock AMI_GetWave did not return clock_times after the simulation started. Bob noted that the IBIS 7.0 Known Issues Document now contains a section for editorial issues with BIRDs approved for the next release. He said Randy controls this document and asked Curtis to start an email thread to discuss whether we could handle it that way. - Curtis: Motion to adjourn. - David: Second. - Arpad: Thank you all for joining. AR: Fangyi to email his "AMI Redriver Flow" presentation to the ATM list. AR: Arpad to ask Steve Parker to post the presentation to the ATM archives. AR: Curtis to start an email thread about whether the BIRD204 modifications can be handled in Editorial. ------------- Next meeting: 26 January 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives